What consensus algorithm does Qdrant use to keep cluster metadata consistent across nodes, and what does it coordinate?

Qdrant uses Raft to keep cluster metadata consistent across nodes. That metadata includes the collection configuration (vector params, HNSW config, quantization config, optimizer config), the cluster topology (which nodes exist and which are healthy), shard placement (which node hosts which shard and which replica is primary), shard key definitions, and aliases. Raft is a leader-based consensus algorithm: a group of nodes elects a leader, all metadata writes go through the leader, the leader replicates the entry to followers, and once a quorum has acknowledged it the entry is committed and applied to the state machine. This gives a strongly consistent, linearizable view of the cluster's configuration even in the presence of node failures, as long as a quorum is available.

The critical distinction is what Raft does not coordinate: point data. Your vectors are not replicated through Raft. Point data replication is a separate mechanism in which each shard has a primary that accepts writes, appends them to its WAL, and streams WAL entries to its replicas. Replicas apply the same operations in the same order, which is a primary-backup log-shipping scheme, not consensus. The reason for the split is cost: Raft requires a quorum round trip for every write, which would be far too slow for high-throughput vector ingest. Metadata changes are rare, so paying the Raft cost for them is acceptable; point writes are frequent, so they use a cheaper replication mechanism with configurable consistency levels. Understanding this split is what lets you reason about failure modes: losing the Raft leader triggers an election and a brief window where metadata changes cannot be committed, but existing point data and queries continue to work. Losing a shard's primary triggers a failover to a replica, which is a data-plane event, not a Raft event.

The trade-off is strong consistency for metadata against the availability cost of requiring a quorum. If a cluster loses quorum - for example, two of three Raft nodes are down - it cannot commit metadata changes, which means you cannot create collections, change configs, or rebalance shards until quorum is restored. Reads and existing point writes can often continue under the consistency settings you have chosen, but any operation that requires a metadata change will block. The common mistake is assuming Raft replicates your vectors. It does not - if you want point data to survive a node loss, you need replication_factor greater than one, which is a separate setting. The second mistake is assuming the cluster becomes unavailable when the Raft leader fails. It does not; a new leader is elected, and the unavailability window is only as long as the election takes. The third mistake is conflating Raft consistency with read consistency. The consistency levels you set on reads (one, majority, all) govern point data freshness, not metadata consistency. Version note: Qdrant's use of Raft has evolved - in older versions there was a single consensus group for the whole cluster, while newer versions have moved toward per-collection consensus and richer topology management. The exact behavior of metadata operations during partial failures differs between versions.

Version-dependent: Qdrant's consensus implementation has changed across releases. Early versions used a single Raft group for the entire cluster; more recent versions have moved toward per-collection consensus and more sophisticated placement and rebalancing. The exact metadata that goes through consensus, the behavior during quorum loss, and the API for inspecting consensus state all differ. If you are designing for high availability, verify the failure behavior on your version rather than relying on a general description of Raft, and test the specific scenarios (leader loss, quorum loss, node replacement) that matter for your SLA.